fix(layout): place the first column on the right in RTL sections - #3953

A section carrying `w:sectPr/w:bidi` fills its columns left to right, so the
first paragraph of a Hebrew two-column section lands in the LEFT column. Word
puts it on the right (ECMA-376 §17.6.1), and `SectionDirectionContext` already
documents `pageDirection` as governing columns -- but no function in the column
geometry ever received a direction.

`ColumnLayout` now carries an optional `direction`, and `buildColumnGeometry`
mirrors the strip about the CONTENT AREA when it is `'rtl'`. Indices stay in
fill order, so every consumer that walks columns 0..n-1 keeps filling in
document order and only the painted x changes; fill, hit testing, separators,
balancing, floating anchors and footnotes all follow from that single source.
The mirror axis is the content area and not the strip's own span because
explicit widths are not scaled to fill it -- a strip that underfills must end
up against the right margin with the slack on the left.

Four consumers needed direction awareness of their own, and each failed
silently without it:

- `getColumnAtX` walked the geometry assuming x ascends with the index.
- `toBalancingColumns` rebuilt the layout field by field and dropped the axis,
  so the balanced last page of an RTL section laid out left to right while
  every earlier page of the same section laid out right to left.
- Footnote column attribution broke on the first match under the same
  ascending assumption, collapsing a page's notes into column 0: the left
  column's notes printed under the right column and its own note area stayed
  empty.
- The DOM painter's separator gate read "content past the separator" as
  "content to the right", so a section whose content never left the first
  column drew a line Word does not draw.

Absent `direction`, every path is byte-identical to before: verified across
46,080 comparisons of geometry and hit testing over 960 LTR configurations
and 6 content widths.

…trails

Review follow-up on superdoc#3953. The RTL branch of the separator gate tested the
fragment's LEFT edge, the same edge the LTR branch tests, which leaves the two
asymmetric for anything wider than a column.

`page.items` carries anchored drawings alongside column content, so a
page-relative watermark or logo sits at `x = 0` spanning the page. Going right
it is never past the separator; going left, a left-edge test always puts it
past. An RTL section with `w:sep="1"` whose text all fits in the first column
therefore drew a separator on the strength of the watermark alone -- a line
Word does not draw, which is exactly what this gate exists to prevent.

Each branch now tests the edge that trails in its own fill direction: the left
edge going right, the right edge going left.

… not by an edge

The column-separator gate asks whether a LATER column holds content, because
Word draws no line next to an empty column. It answered by comparing a fragment
edge against the separator x, choosing whichever edge trails in the fill
direction. No edge can answer that question.

Content wider than its column does not sit inside it, and `resolveTableFrame`
places an over-wide table at a NEGATIVE offset from its column whenever the
table is right-aligned or centred -- and `end` is the default justification for
any bidiVisual table. So in an RTL section a wide table starts left of its own
column and ends past the separator, while never having left the later column:
both of its edges lie on the wrong side, and so does its origin. A negative
`w:ind` puts a paragraph's origin in the gutter with the same effect.

Use `fragment.columnIndex` instead -- the engine's own record of the owning
column, written for paragraphs and tables as they are laid out, and documented
as the field to trust "when overflow crosses margins". Geometry is the fallback
for a fragment carrying no such record, and it is containment rather than
`getColumnAtX` because containment can answer "no column": that is what keeps
page-anchored objects out of the gate, a full-width watermark belonging to none.

`findColumnContaining` is the new contracts helper for that fallback, the strict
counterpart to `getColumnAtX`, which must clamp because a click has to select
something. Its spans are half-open so that columns authored with no gutter do
not both claim the boundary they share -- the boundary is exactly where the
later column's content begins, and an inclusive bound would give it to the
earlier column in LTR but not in RTL, making the two directions disagree.

The painter's private separator helper now returns the geometry rather than bare
x positions, so each separator stays paired with the column it follows instead
of relying on array-index alignment.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ts origin

Review follow-up on superdoc#3953. The separator gate reads `fragment.columnIndex`
first and falls back to geometry, but the fallback tested containment of the
fragment's ORIGIN, and the previous commit's rationale assumed the engine
records `columnIndex` for paragraphs. It does not: the paginator writes it for
tables (layout-table.ts) and for footnote bodies, and nowhere for an ordinary
paragraph fragment. Paragraphs therefore always reach the fallback.

That matters because a paragraph's origin can sit outside its own column. A
negative `w:ind` hangs it into the gutter, and containment then answers "no
column" -- so a later column holding only an outdented paragraph registered as
empty and its separator was suppressed, a line Word draws. The same shape
applies to an over-wide right-aligned or centred table, which
`resolveTableFrame` places at a negative offset from its column.

Attribution is now by overlap: the column whose span the fragment covers most,
ties going to the earliest in fill order. Anything at least as wide as the whole
content area still belongs to no column, which is what keeps page-anchored
objects out of the gate -- a full-width watermark overlaps every column without
being content of any, and counting it would draw a separator on a page whose
text never left the first column.

Both directions are covered: an outdented paragraph alone in a later column now
draws its separator, and the watermark case still does not.

…dges

Follow-up to cubic's review of 2438bd9, and to three defects a QA pass over the
same function found. All four are in code this PR added.

`columnOwningSpan` answers "which column owns this box", and the separator gate
asks it "does a LATER column hold content". A wrong answer that names a later
column INVENTS a rule Word does not draw; one that names an earlier column or
none SUPPRESSES a rule Word does draw. Both were reachable.

**The width bound measured the strip, not the page.** Explicit widths are floored
to >= 1px but never CAPPED -- nothing clamps their sum -- so an authored
`w:num="2"` with two over-wide `w:col/@w` produces a strip WIDER than the content
area. Against the strip's own span a page-wide graphic then measures as merely
partial, and overlap attribution hands it to whichever column it covers most:
`widths: [150, 600]` on a 624px area gives it 150px of column 0 against 426px of
column 1. The threshold is now the smaller of the two bounds. Not RTL-specific,
which the report had it as: the LTR strip runs 0..150 / 198..798 and the mirrored
RTL one 474..624 / -174..426, and the graphic wins column 1 in both.

**Neither edge test existed.** Attribution was overlap after a containment test,
and both are wrong for a case the other answers, because an indent and an
over-wide box produce the same shape from opposite causes:

  - A box on a column's LEADING edge is that column's, fit or no fit -- ordinary
    content, and content wider than its column, which overflows from that edge.
    Overlap alone gets it wrong once the columns are unequal enough for the spill
    to cover more of the neighbour: `widths: [100, 400]`, a 500px box at column
    0's edge, 100px of its own column against 352px of the next.
  - A box on a column's TRAILING edge is that column's too, and that is a
    different question rather than a mirror. An indent moves only the leading
    edge, so a paragraph outdented FURTHER than the gutter has its origin inside
    the previous column while still ending exactly at its own column's trailing
    edge -- and containment then read its column as empty. Measured on equal
    2-col geometry over 624px (col0 [0,288), col1 [336,624)): a column-1
    paragraph outdented 72px is the box [264, 624].

Containment survives as the third rule, now fit-checked, and overlap as the
fourth. `balanceSectionOnPage`'s `ordinalOf` reached the same four rules in the
same order for the same reasons; the two differ only at the end, where a sort key
must name a column and this may answer `null`. They should be one shared helper
in `contracts`, and are not yet.

**Folded the strip bounds out of `Math.min(...map)`.** `w:num` is bounded at 45 by
the schema but nothing in the pipeline enforces it, and a host-built layout with a
six-figure count overflowed the argument stack -- a paint-time crash out of
`paint()`, taking the whole document with it, from a function whose only job is to
answer conservatively.

Two further fixes at the call site, from the same QA pass:

**A float is not column content, and no width threshold can recognise one.** The
threshold catches a full-width watermark, which is what it was written for, but
`page.items` is `page.fragments.map(...)` with no anchor filtering, and an
anchored object carries its own `measure.width` -- so a narrow one is the ordinary
case. A 200px logo at page x 500 on a 2-column page whose text never leaves column
0 has its origin inside column 1 and lit the gate. Excluded by identity
(`isAnchored`) instead. Every float, not only page-relative ones: `hRelativeFrom`
is consumed at layout time and never reaches the fragment, and there is no
evidence here about whether Word draws a rule beside a column holding a floating
object and no text. Word's rule tracks text, and the gate is deliberately
asymmetric, so the conservative reading is also the simpler one.

**An out-of-range `columnIndex` is rejected, not clamped.** Clamping turned any
stale or corrupt value into a real index -- `columnIndex: 5` on a two-column page
became 1 -- which is exactly the "a later column holds content" the gate asks
about, invented out of a number describing no column on the page. Falling through
to geometry answers from the fragment's actual position. Floored first, so float
drift on a valid index still resolves.

Eleven tests, each pinning one rule. The page-bound and both edge tests were
mutation-checked: restoring the old threshold or removing either edge rule fails
exactly one test each, and three different ones.

cubic's review caught that the test standing for the width gate's rejection path
never reaches it, and the same mistake was written into the gate's own comment as
its justification.

An outdented paragraph cannot reach that step. A negative `w:ind` widens the
fragment by exactly the outdent it shifts by, so `x + width` lands on its own
column's trailing edge for EVERY outdent -- the trailing-edge rule answers first
and the gate never sees the box. On equal 2-col geometry over 624px (col0
[0,288), col1 [336,624)), a column-1 paragraph outdented 72px is [264, 624], and
624 IS column 1's trailing edge. Any other outdent lands there too.

That fixture was the only guard on the gate, so the gate had none. Measured
rather than assumed: replacing the width comparison with unconditional origin
trust left all 39 tests in this file passing.

The shape that does reach it is a centred over-wide box. `resolveTableFrame`
centres an over-wide table inside its column at
`col.x + (col.width - width) / 2`, a NEGATIVE offset once the table is wider than
the column, so it begins inside an earlier column without ever having left its
own -- and unlike the outdent, its right edge lands nowhere in particular. A
400px box centred in column 1 is [280, 680]: 680 misses column 1's 624 by 56, the
origin 280 falls inside column 0, and 400 does not fit a 288px column, so the
origin is rejected and overlap answers column 1, 288px against 8px. Under the
same mutation this fixture fails, and it is the only test that does.

Both comments now say what the mistake was rather than quietly swapping the
fixture: a reader who checks the old justification finds a counterexample and
has no way to tell how far the error spread.

Test and comments only; no behavior change.

…s content

`getColumnAtX`'s mirrored branch tested an INCLUSIVE upper bound, so it disagreed
with the half-open spans that `findColumnContaining` and the geometry itself use.

With `w:space="0"` (ECMA-376 §17.6.3) adjacent columns share an edge, and in an RTL
section that shared edge is the earlier fill column's own left edge -- exactly where
its content is placed -- so the inclusive form handed it to the LATER column and
every column boundary in a zero-gutter RTL section resolved one column too far. Two
columns over 602px mirror to column 0 at [301,602) and column 1 at [0,301):
`findColumnContaining(301)` answered 0 and `getColumnAtX(301)` answered 1, so the two
resolvers disagreed at the one point they can be made to disagree about. The same
bound also claimed the point on a column's trailing edge, which is gutter and belongs
to the column preceding it in fill order.

`cx <` is correct on both counts and makes the two resolvers agree everywhere they
can both answer.

Fixed here rather than one PR up the stack, where it was first written. This branch
introduces the mirrored branch and its inclusive bound, so it is where the defect
enters the tree; leaving it for superdoc#3962 meant superdoc#3953 and superdoc#3961 would both merge with a
line already known to be wrong. Dormant in production either way -- nothing assigns
`ColumnLayout.direction` yet -- but the review record should not carry a known defect
across two merges when the fix is three lines.

The RTL case in position-hit.test.ts worked its geometry out as column 1 spanning
336..528; the mirrored geometry puts it at 312..504, a full gutter off. Corrected,
with the derivation spelled out, since that comment misleads a reader of this diff
today.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>